This invention is generally related to computer systems having an input/output (I/O) subsystem in a multiple bus architecture, and more specifically to accessing an I/O messaging unit from a secondary bus.
To help eliminate the performance bottleneck presented by the use of I/O devices or peripherals in multiple bus computer systems, system designers have turned to the concept of an intelligent I/O subsystem. Such a subsystem typically includes a subsystem processor and a local memory sharing a local bus that is separate from the host system busses. In such a computer system, interrupt-intensive I/O tasks such as transfers between peripheral devices are redirected from the host processor to the I/O subsystem in order to free resources on the system busses. Such an architecture also allows I/O performance to increase independently of the host processor so as to alleviate the I/O bottleneck. FIG. 1 illustrates an exemplary multiple bus computer system 100 featuring an intelligent I/O subsystem 110.
The computer system 100 of FIG. 1 is based on the industry-standard Peripheral Components Interconnect (PCI) specification generally defined by the PCI Special Interest Group in PCI Local Bus Specification, Revision 2.1, Oct. 21, 1994. The system features two physically separate PCI system busses, primary PCI bus 114 and secondary PCI bus 118. A bridge unit 126 combines the two system busses into one logical bus having a single PCI address space that is compliant with the PCI-to-PCI Bridge Architecture Specification, Revision 1.0, also published by the PCI Special Interest Group, Apr. 5, 1994. Agents such as host processor 164 and peripheral devices such as first PCI agent 172 and second PCI agent 176 reside on the system busses and communicate transparently with each other through the bridge. A third or local bus 122 is coupled to the system busses via the primary and secondary address translation units (P_ATU 134, S_ATU 146). The ATUs support transactions between the PCI address space and the I/O subsystem local address space. A subsystem processor 152 and memory controller unit (MCU) 156 coupled to a local memory communicate with each other using the local bus 122. The subsystem processor 152 and local memory bring intelligence to the I/O subsystem by processing the I/O message tasks at the I/O subsystem level versus the host processor 164 level.
The I/O subsystem also includes an I/O messaging unit (MU) 130 which is closely coupled to or, alternatively, a part of the P_ATU 134. At a lower level, the MU facilitates I/O transactions, i.e. the transfer of data between the PCI agents on the primary bus and the subsystem processor and local memory. On a higher level, the MU provides for data transfer between the host operating system and the I/O subsystem through the posting of requests and completions of I/O transactions. I/O transactions involve the transfer and performing of I/O messages that comply with the Intelligent I/O (I2O®) Architecture Specification, Version 1.5, March 1997. The specification is designed to simplify the task of building and maintaining high performance I/O systems. The I2O specification provides a common I/O device driver and I/O (or I2O) protocol that is independent to both the specific control device and the host operating system.
More particularly, the I2O specification supports message passing between agents and the I/O subsystem. These I/O messages typically specify operations to be performed by the subsystem processor 152 and MCU 156. Such messages are described in the I2O specification and are of a higher level format than conventional read and write transactions, and may include multiple PCI and/or local bus read and write transactions. For example, an I/O message may contain a sequence of transactions that request the I/O subsystem to read data from local memory and write the data to an agent on the primary PCI bus 114. Another example is an I/O message that provides an agent with the address information required for performing a transaction with another agent on the primary PCI bus 114. Such a message is typically used by a peripheral device to communicate with another device while bypassing the host processor 164.
In general, the host processor 164 is configured (through the host operating system and other software) to place the I/O messages in host memory 168, and initialize the MU 130 by providing pointers to the I/O messages. These pointers are stored in message queues and are accessed through the MU 130. The MU guarantees a fixed address range on the primary bus which may be used by the PCI system and the I/O subsystem to access the pointers and the I/O messages. The message queues may be stored in host memory 168, or in I/O memory 160 and may be accessed via the MU 130 in response to I/O requests received from agents on the primary bus 114 and from the subsystem processor 152.
The conventional mechanism for processing I/O requests by the MU involves only the P_ATU 134 and the primary PCI bus 114. Each ATU normally provides a two-way communication and data flow path between the local bus 122 and the corresponding PCI system bus. The ATU implements an address windowing scheme to determine which requests are to be claimed and translated to the appropriate bus. Transactions where a PCI bus master, such as PCI agent 164, is accessing the local bus 122 through the ATU are called inbound transactions. Each ATU may be programmed to define an inbound address translation window, where requests having PCI addresses within the window are claimed by the ATU and translated into a local bus address.
The MU 130 uses a portion of the primary inbound translation window of the P_ATU 134 to respond to I/O requests, as distinguished from other requests that seek transactions involving the local bus 122, from agents on the primary bus 114. The MU also uses the PCI configuration registers of the P_ATU for control and status information. In the conventional scheme, the I/O requests are typically initiated by the host processor 164 or other agent 172 on the primary PCI bus 114, and directed to the MU portion of the primary inbound translation window.
However, in the conventional scheme, an intelligent agent on the secondary PCI bus 118 does not have direct access to the MU 130 or the I2O protocol. Rather, the agent on the secondary bus requests the host processor (through the bridge 126) to perform the I2O protocol on its behalf. This increases the burden on the host processor, especially as the number of intelligent agents on the secondary bus 118 increase.
Therefore, a mechanism is desirable which allows the intelligent agent on the secondary bus to directly access the MU 130 in order to perform the I2O protocol while minimizing interaction with the host processor 164.
Preferably, such a mechanism should allow agent software that employs the I2O protocol to be portable, i.e., applicable without significant modifications, as to requests originating from both the primary and secondary busses. In addition, agents on both busses should be able to access the same amount of local memory in preferably the same address space when interfacing through the ATUs, so that the agents may be moved from one bus to another without the need for reconfiguring the software in each agent. In other words, the mechanism should not require knowledge by the agents of which bus they are located on before they are able to properly implement the I2O protocol. Finally, the mechanism for accessing the messaging unit should sacrifice the least amount of PCI addresses given the constraint of fixed address space boundaries in the PCI bus specification.
One possible technique that may facilitate I2O transactions from the secondary bus would be to add a second MU closely coupled to the S_ATU 146. The second MU would perform substantially the same as the messaging unit 130 in FIG. 1, except that the second MU would be configured to claim a portion of the S_ATU address space. This dual MU architecture, however, may present an additional problem when combined with the need for maintaining portability in agent software by requiring that the P_ATU and S_ATU address translation window (including the address range for the first and second MUs) to be the same. Having identical address translation windows for the P_ATU 134 and S_ATU 146 may require a scheme to manage several pairs of message queues in the MUs simultaneously, because there would exist a pair of pointers to the same I/O message, i.e., two pointers to the same location in host memory. This mechanism would require an additional data coherency protocol to support the dual MU mechanism. Such a coherency mechanism would require one MU to “snoop” or be aware and observe the actions of the other MU. When an I2O transaction occurs, the silent MU would be required to invalidate some of its available message pointers to data, due to the activity of the other MU performing a valid transaction with the same data. Thus, a potentially complex data coherency issue arises when using such a dual MU design to achieve portability in PCI agent software.
Therefore, in view of the foregoing, there is a need for a mechanism that allows the I2O protocol to be performed by agents on both the primary and secondary PCI busses, where the mechanism should also permit the development of MU accessing software.